Cổng API Frontend: GraphQL Federation và Schema Stitching

Trong thế giới phát triển ứng dụng web hiện đại, việc quản lý dữ liệu từ nhiều nguồn khác nhau có thể là một thách thức lớn. Khi các ứng dụng ngày càng phức tạp và áp dụng kiến trúc microservices, nhu cầu về một phương pháp thống nhất và hiệu quả để truy cập dữ liệu trở nên tối quan trọng. Một Cổng API Frontend (Frontend API Gateway) hoạt động như một điểm vào trung tâm cho các ứng dụng client, tổng hợp dữ liệu từ các dịch vụ backend khác nhau và cung cấp trải nghiệm liền mạch cho cả nhà phát triển và người dùng cuối. Bài viết này khám phá hai kỹ thuật mạnh mẽ để xây dựng Cổng API Frontend: GraphQL Federation và Schema Stitching.

Cổng API Frontend là gì?

Cổng API Frontend là một mẫu kiến trúc trong đó một máy chủ chuyên dụng đóng vai trò trung gian giữa các client frontend (ví dụ: trình duyệt web, ứng dụng di động) và nhiều dịch vụ backend. Nó đơn giản hóa việc tìm nạp dữ liệu bằng cách:

• Tổng hợp dữ liệu: Kết hợp dữ liệu từ nhiều nguồn vào một phản hồi duy nhất.
• Chuyển đổi dữ liệu: Điều chỉnh định dạng dữ liệu cho phù hợp với nhu cầu của frontend.
• Trừu tượng hóa sự phức tạp: Che giấu sự phức tạp của các dịch vụ backend khỏi client.
• Thực thi bảo mật: Triển khai các chính sách xác thực và ủy quyền.
• Tối ưu hóa hiệu suất: Lưu trữ dữ liệu thường xuyên truy cập vào bộ nhớ đệm và giảm số lượng yêu cầu mạng.

Về cơ bản, nó triển khai mẫu Backend for Frontend (BFF) ở quy mô lớn và trao quyền cho các nhóm front-end kiểm soát nhiều hơn các API mà họ sử dụng. Trong các tổ chức lớn hơn, việc để front-end quản lý và sắp xếp các API của riêng mình có thể giúp tăng tốc độ phân phối và giảm sự phụ thuộc vào các nhóm backend.

Tại sao nên sử dụng GraphQL cho Cổng API Frontend?

GraphQL là một ngôn ngữ truy vấn cho API và một môi trường thời gian chạy để thực hiện các truy vấn đó với dữ liệu hiện có của bạn. Nó cung cấp một số lợi thế so với các API REST truyền thống, khiến nó rất phù hợp để xây dựng Cổng API Frontend:

• Tìm nạp dữ liệu hiệu quả: Client chỉ yêu cầu dữ liệu họ cần, giảm thiểu việc tìm nạp thừa (over-fetching) và cải thiện hiệu suất.
• Kiểu dữ liệu mạnh: Các schema GraphQL định nghĩa cấu trúc của dữ liệu, cho phép các công cụ và việc xác thực tốt hơn.
• Tự kiểm tra (Introspection): Client có thể khám phá dữ liệu và các hoạt động có sẵn thông qua việc tự kiểm tra schema.
• Khả năng thời gian thực: GraphQL subscriptions cho phép cập nhật dữ liệu thời gian thực.

Bằng cách tận dụng GraphQL, một Cổng API Frontend có thể cung cấp một giao diện linh hoạt, hiệu quả và thân thiện với nhà phát triển để truy cập dữ liệu từ nhiều dịch vụ backend. Điều này hoàn toàn trái ngược với các phương pháp truyền thống sử dụng nhiều điểm cuối REST, mỗi điểm cuối cần được truy vấn riêng lẻ và thường trả về nhiều dữ liệu hơn mức cần thiết.

GraphQL Federation: Một phương pháp tiếp cận phân tán

GraphQL Federation là gì?

GraphQL Federation là một kỹ thuật mạnh mẽ để xây dựng một API GraphQL phân tán bằng cách kết hợp nhiều dịch vụ GraphQL (được gọi là "subgraphs") thành một schema thống nhất duy nhất. Mỗi subgraph chịu trách nhiệm cho một miền hoặc nguồn dữ liệu cụ thể, và cổng Federation điều phối các truy vấn qua các subgraph này.

Khái niệm cốt lõi xoay quanh một supergraph, một schema GraphQL thống nhất duy nhất đại diện cho toàn bộ API. Supergraph này được xây dựng bằng cách kết hợp các schema GraphQL nhỏ hơn, được gọi là subgraphs, mỗi subgraph đại diện cho một microservice hoặc nguồn dữ liệu cụ thể. Cổng Federation chịu trách nhiệm định tuyến các truy vấn GraphQL đến các subgraph thích hợp và kết hợp các kết quả thành một phản hồi duy nhất.

GraphQL Federation hoạt động như thế nào

1. Định nghĩa Subgraph: Mỗi microservice phơi bày một API GraphQL (một subgraph) định nghĩa dữ liệu và các hoạt động của riêng nó. Các schema này bao gồm các chỉ thị (directives) để cho cổng Federation biết cách phân giải các loại và trường. Các chỉ thị chính bao gồm `@key`, `@external`, và `@requires`.
2. Kết hợp Supergraph: Cổng Federation (ví dụ: Apollo Gateway) lấy các schema từ mỗi subgraph và kết hợp chúng thành một schema thống nhất duy nhất (supergraph). Quá trình này bao gồm việc giải quyết các xung đột về loại và trường và thiết lập các mối quan hệ giữa các loại trên các subgraph khác nhau.
3. Lập kế hoạch và thực thi truy vấn: Khi một client gửi một truy vấn GraphQL đến cổng, cổng sẽ phân tích truy vấn và xác định những subgraph nào cần được truy vấn để đáp ứng yêu cầu. Sau đó, nó phân phối truy vấn đến các subgraph thích hợp, thu thập kết quả và kết hợp chúng thành một phản hồi duy nhất, được trả về cho client.

Ví dụ: Nền tảng thương mại điện tử với GraphQL Federation

Hãy xem xét một nền tảng thương mại điện tử với các microservices riêng biệt cho sản phẩm, khách hàng và đơn hàng.

• Subgraph Sản phẩm: Quản lý thông tin sản phẩm (tên, mô tả, giá, v.v.).
• Subgraph Khách hàng: Quản lý dữ liệu khách hàng (tên, địa chỉ, email, v.v.).
• Subgraph Đơn hàng: Quản lý thông tin đơn hàng (ID đơn hàng, ID khách hàng, ID sản phẩm, tổng tiền, v.v.).

Mỗi subgraph phơi bày một API GraphQL, và cổng Federation kết hợp các API này thành một supergraph duy nhất. Một client sau đó có thể truy vấn supergraph để lấy thông tin về sản phẩm, khách hàng và đơn hàng trong một yêu cầu duy nhất.

Ví dụ, một truy vấn để lấy tên của một khách hàng và lịch sử đơn hàng của họ có thể trông như sau:

query GetCustomerAndOrders($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    orders {
      id
      orderDate
      totalAmount
    }
  }
}

Cổng Federation sẽ định tuyến truy vấn này đến các subgraph Khách hàng và Đơn hàng, lấy dữ liệu cần thiết và kết hợp nó thành một phản hồi duy nhất.

Lợi ích của GraphQL Federation

• Truy cập dữ liệu đơn giản hóa: Client tương tác với một điểm cuối GraphQL duy nhất, bất kể các nguồn dữ liệu bên dưới.
• Cải thiện hiệu suất: Việc tìm nạp dữ liệu được tối ưu hóa bằng cách chỉ lấy dữ liệu cần thiết từ mỗi subgraph.
• Tăng khả năng mở rộng: Mỗi subgraph có thể được mở rộng độc lập, cho phép sử dụng tài nguyên tốt hơn.
• Phát triển phi tập trung: Các nhóm có thể phát triển và triển khai các subgraph một cách độc lập, thúc đẩy sự linh hoạt và đổi mới.
• Quản trị schema: Cổng Federation thực thi tính nhất quán và tương thích của schema trên các subgraph.

Công cụ cho GraphQL Federation

• Apollo Federation: Một triển khai mã nguồn mở phổ biến của GraphQL Federation, cung cấp một cổng, một sổ đăng ký schema, và các công cụ để xây dựng và quản lý các API GraphQL liên kết. Apollo Federation nổi tiếng với khả năng mở rộng và xử lý lỗi mạnh mẽ.
• GraphQL Hive: Công cụ này cung cấp sổ đăng ký schema và quản trị cho các dịch vụ GraphQL liên kết, cung cấp các tính năng như phát hiện thay đổi, phân tích sử dụng và kiểm tra schema. Nó tăng cường khả năng hiển thị và kiểm soát supergraph.

Schema Stitching: Một phương pháp tiếp cận thay thế

Schema Stitching là gì?

Schema Stitching là một kỹ thuật khác để kết hợp nhiều schema GraphQL thành một schema thống nhất duy nhất. Không giống như Federation, Schema Stitching thường liên quan đến một quy trình thủ công hơn để xác định cách các loại và trường từ các schema khác nhau được kết nối. Mặc dù Federation được coi là một giải pháp hiện đại và mạnh mẽ hơn, Schema Stitching có thể là một lựa chọn khả thi cho các trường hợp sử dụng đơn giản hơn hoặc khi di chuyển từ các API GraphQL hiện có.

Schema Stitching hoạt động như thế nào

1. Định nghĩa Schema: Mỗi microservice phơi bày một API GraphQL với schema riêng của nó.
2. Logic kết nối (Stitching Logic): Một lớp kết nối (thường được triển khai bằng các thư viện như GraphQL Tools) định nghĩa cách các loại và trường từ các schema khác nhau được kết nối. Điều này bao gồm việc viết các hàm resolver để tìm nạp dữ liệu từ các dịch vụ bên dưới và ánh xạ nó vào schema thống nhất.
3. Schema thống nhất: Lớp kết nối kết hợp các schema riêng lẻ thành một schema thống nhất duy nhất được phơi bày cho client.

Ví dụ: Kết nối Sản phẩm và Đánh giá

Hãy tưởng tượng hai dịch vụ GraphQL riêng biệt: một cho sản phẩm và một cho đánh giá.

• Dịch vụ Sản phẩm: Cung cấp thông tin về sản phẩm (ID, tên, mô tả, giá).
• Dịch vụ Đánh giá: Cung cấp đánh giá cho sản phẩm (ID, ID sản phẩm, xếp hạng, bình luận).

Sử dụng Schema Stitching, bạn có thể tạo một schema thống nhất cho phép client lấy thông tin sản phẩm và đánh giá trong một truy vấn duy nhất.

Bạn sẽ định nghĩa một hàm resolver trong lớp kết nối để tìm nạp các đánh giá cho một ID sản phẩm nhất định từ Dịch vụ Đánh giá và thêm chúng vào loại Product trong schema thống nhất.

// Ví dụ (Khái niệm): Logic kết nối sử dụng GraphQL Tools
const { stitchSchemas } = require('@graphql-tools/stitch');

const productsSchema = ... // Định nghĩa schema sản phẩm của bạn
const reviewsSchema = ... // Định nghĩa schema đánh giá của bạn

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: productsSchema,
    },
    {
      schema: reviewsSchema,
      transforms: [
        {
          transformSchema: (schema) => schema,
          transformRequest: (originalRequest) => {
            return originalRequest;
          },
          transformResult: (originalResult) => {
            return originalResult;
          }
        }
      ],
    },
  ],
  typeDefs: `
    extend type Product {
      reviews: [Review]
    }
  `,
  resolvers: {
    Product: {
      reviews: {
        resolve: (product, args, context, info) => {
          // Tìm nạp các đánh giá cho sản phẩm từ Dịch vụ Đánh giá
          return fetchReviewsForProduct(product.id);
        },
      },
    },
  },
});

Ví dụ này minh họa khái niệm cốt lõi của việc kết nối các schema lại với nhau. Lưu ý sự cần thiết của các resolver tùy chỉnh để tìm nạp trường `reviews`. Chi phí bổ sung này của việc viết mã resolver cho mỗi mối quan hệ có thể làm cho quá trình phát triển chậm hơn so với sử dụng Federation.

Lợi ích của Schema Stitching

• API thống nhất: Client truy cập một điểm cuối GraphQL duy nhất, đơn giản hóa việc truy cập dữ liệu.
• Áp dụng từng bước: Schema Stitching có thể được triển khai từng bước, cho phép bạn dần dần di chuyển sang một API thống nhất.
• Linh hoạt: Schema Stitching cung cấp nhiều quyền kiểm soát hơn về cách các schema được kết hợp, cho phép bạn tùy chỉnh logic kết nối để đáp ứng các nhu cầu cụ thể.

Nhược điểm của Schema Stitching

• Cấu hình thủ công: Schema Stitching đòi hỏi cấu hình thủ công cho logic kết nối, điều này có thể phức tạp và tốn thời gian.
• Chi phí hiệu suất: Các hàm resolver có thể gây ra chi phí hiệu suất, đặc biệt nếu chúng liên quan đến các phép biến đổi dữ liệu phức tạp.
• Khả năng mở rộng hạn chế: Schema Stitching có thể khó mở rộng hơn Federation, vì logic kết nối thường được tập trung.
• Quyền sở hữu schema: Có thể dẫn đến sự mơ hồ về quyền sở hữu schema, đặc biệt nếu các nhóm khác nhau quản lý các dịch vụ được kết nối.

Công cụ cho Schema Stitching

• GraphQL Tools: Một thư viện phổ biến để xây dựng và thao tác các schema GraphQL, bao gồm hỗ trợ cho Schema Stitching.
• GraphQL Mesh: GraphQL Mesh cho phép bạn sử dụng ngôn ngữ truy vấn GraphQL để truy cập dữ liệu từ nhiều nguồn khác nhau như API REST, cơ sở dữ liệu và gRPC. Nó có thể kết nối các API này thành một schema GraphQL thống nhất.

GraphQL Federation vs. Schema Stitching: Một so sánh

Cả GraphQL Federation và Schema Stitching đều cung cấp các cách để kết hợp nhiều schema GraphQL thành một API duy nhất, nhưng chúng khác nhau về cách tiếp cận và khả năng.

Tính năng	GraphQL Federation	Schema Stitching
Cách tiếp cận	Kết hợp phân tán, tự động	Cấu hình tập trung, thủ công
Độ phức tạp	Độ phức tạp thấp hơn để bảo trì và mở rộng	Độ phức tạp cao hơn do logic resolver thủ công
Khả năng mở rộng	Được thiết kế cho các hệ thống phân tán quy mô lớn	Ít khả năng mở rộng hơn, thường được sử dụng cho các ứng dụng nhỏ hơn
Quản trị schema	Quản trị và xác thực schema tích hợp sẵn	Yêu cầu quản lý và phối hợp schema thủ công
Công cụ	Hệ sinh thái công cụ và thư viện mạnh mẽ (ví dụ: Apollo Federation)	Yêu cầu nhiều công cụ và cấu hình tùy chỉnh hơn
Trường hợp sử dụng	Kiến trúc microservices, API quy mô lớn, phát triển phi tập trung	Ứng dụng nhỏ hơn, di chuyển từng bước, yêu cầu tùy chỉnh cụ thể

Khi nào nên sử dụng GraphQL Federation: Chọn Federation khi bạn có một kiến trúc microservices phức tạp, cần mở rộng API của mình và muốn trao quyền cho các nhóm độc lập quản lý các subgraph của riêng họ. Nó cũng đơn giản hóa việc quản lý và quản trị schema.

Khi nào nên sử dụng Schema Stitching: Cân nhắc Schema Stitching khi bạn có một API đơn giản hơn, cần nhiều quyền kiểm soát hơn đối với logic kết nối, hoặc đang di chuyển từ các API GraphQL hiện có. Tuy nhiên, hãy nhận thức về những phức tạp tiềm ẩn và các hạn chế về khả năng mở rộng.

Triển khai Xác thực và Ủy quyền

Bất kể bạn chọn GraphQL Federation hay Schema Stitching, việc triển khai xác thực và ủy quyền là rất quan trọng để bảo mật Cổng API Frontend của bạn. Có một số cách tiếp cận bạn có thể thực hiện:

• Xác thực ở cấp Gateway: API Gateway xử lý xác thực và ủy quyền trước khi định tuyến yêu cầu đến các dịch vụ backend. Cách tiếp cận này tập trung hóa logic bảo mật và đơn giản hóa các dịch vụ backend. Các phương pháp phổ biến bao gồm xác thực JWT (JSON Web Token) và OAuth 2.0.
• Xác thực ở cấp Dịch vụ: Mỗi dịch vụ backend tự xử lý việc xác thực và ủy quyền của riêng mình. Cách tiếp cận này cung cấp quyền kiểm soát chi tiết hơn về bảo mật nhưng có thể phức tạp hơn để quản lý.
• Cách tiếp cận kết hợp (Hybrid): Một sự kết hợp giữa xác thực ở cấp gateway và cấp dịch vụ. Gateway xử lý xác thực ban đầu, và các dịch vụ backend thực hiện các kiểm tra ủy quyền chi tiết hơn.

Ví dụ: Xác thực JWT với Apollo Federation

Với Apollo Federation, bạn có thể cấu hình gateway để xác thực các token JWT được bao gồm trong tiêu đề yêu cầu. Gateway sau đó có thể chuyển thông tin người dùng được trích xuất từ token đến các subgraph, các subgraph này có thể sử dụng thông tin này để ủy quyền.

// Ví dụ (Khái niệm): Cấu hình Apollo Gateway với xác thực JWT
const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
    // ... cấu hình subgraph của bạn
  ],
  buildService: ({ name, url }) => {
    return new MyCustomService({
      name,  // Tên của subgraph
      url,   // URL của subgraph
    });
  },
});

class MyCustomService extends RemoteGraphQLDataSource {
  willSendRequest({ request, context }) {
    // Lấy người dùng từ context
    const user = context.user;

    // Thêm ID của người dùng vào tiêu đề yêu cầu
    if (user) {
      request.http.headers.set('user-id', user.id);
    }
  }
}

Trong ví dụ này, một dịch vụ tùy chỉnh được tạo ra để sửa đổi các yêu cầu gửi đi để bao gồm ID người dùng được lấy từ JWT. Các dịch vụ hạ nguồn sau đó có thể sử dụng ID này để kiểm tra ủy quyền.

Chiến lược lưu trữ đệm để tối ưu hóa hiệu suất

Lưu trữ đệm (Caching) là điều cần thiết để cải thiện hiệu suất của một Cổng API Frontend. Bằng cách lưu trữ dữ liệu thường xuyên truy cập, bạn có thể giảm tải cho các dịch vụ backend và cải thiện thời gian phản hồi cho client. Dưới đây là một số chiến lược lưu trữ đệm:

• HTTP Caching: Tận dụng các cơ chế lưu trữ đệm HTTP (ví dụ: tiêu đề `Cache-Control`) để lưu trữ các phản hồi trong trình duyệt và các proxy trung gian.
• In-Memory Caching: Sử dụng bộ đệm trong bộ nhớ (ví dụ: Redis, Memcached) để lưu trữ dữ liệu thường xuyên truy cập trên gateway.
• CDN Caching: Sử dụng Mạng phân phối nội dung (CDN) để lưu trữ các tài sản tĩnh và phản hồi API gần hơn với client.
• GraphQL Query Caching: Lưu trữ kết quả của các truy vấn GraphQL dựa trên chuỗi truy vấn và các biến của chúng. Điều này có thể đặc biệt hiệu quả đối với các truy vấn được thực thi thường xuyên. Apollo Server cung cấp hỗ trợ tích hợp cho việc lưu trữ đệm truy vấn.

Khi triển khai lưu trữ đệm, hãy xem xét các chiến lược vô hiệu hóa bộ đệm (cache invalidation) để đảm bảo rằng client nhận được dữ liệu cập nhật. Các chiến lược phổ biến bao gồm:

• Hết hạn theo thời gian: Đặt thời gian hết hạn cố định cho dữ liệu được lưu trong bộ đệm.
• Vô hiệu hóa dựa trên sự kiện: Vô hiệu hóa bộ đệm khi dữ liệu thay đổi trong các dịch vụ backend. Điều này có thể được thực hiện bằng cách sử dụng webhooks hoặc hàng đợi tin nhắn.

Giám sát và Quan sát (Monitoring and Observability)

Giám sát và quan sát là rất quan trọng để đảm bảo sức khỏe và hiệu suất của Cổng API Frontend của bạn. Triển khai giám sát toàn diện để theo dõi các chỉ số chính như:

• Độ trễ yêu cầu: Thời gian cần thiết để xử lý một yêu cầu.
• Tỷ lệ lỗi: Tỷ lệ phần trăm các yêu cầu dẫn đến lỗi.
• Thông lượng: Số lượng yêu cầu được xử lý trên một đơn vị thời gian.
• Sử dụng tài nguyên: Mức sử dụng CPU, bộ nhớ và mạng của gateway và các dịch vụ backend.

Sử dụng truy vết (tracing) để theo dõi các yêu cầu khi chúng đi qua hệ thống, xác định các điểm nghẽn và các vấn đề về hiệu suất. Ghi nhật ký (logging) cung cấp những hiểu biết có giá trị về hành vi của gateway và các dịch vụ backend.

Các công cụ để giám sát và quan sát bao gồm:

• Prometheus: Một hệ thống giám sát và cảnh báo mã nguồn mở.
• Grafana: Một công cụ trực quan hóa và giám sát dữ liệu.
• Jaeger: Một hệ thống truy vết phân tán mã nguồn mở.
• Datadog: Một nền tảng giám sát và bảo mật cho các ứng dụng đám mây.
• New Relic: Một nền tảng trí tuệ kỹ thuật số để giám sát và cải thiện hiệu suất phần mềm.

Bằng cách triển khai giám sát và quan sát mạnh mẽ, bạn có thể chủ động xác định và giải quyết các vấn đề, đảm bảo độ tin cậy và hiệu suất của Cổng API Frontend của mình.

Kết luận

Một Cổng API Frontend được xây dựng với GraphQL Federation hoặc Schema Stitching có thể đơn giản hóa đáng kể việc truy cập dữ liệu, cải thiện hiệu suất và nâng cao trải nghiệm của nhà phát triển trong các ứng dụng web hiện đại. GraphQL Federation cung cấp một giải pháp mạnh mẽ và có khả năng mở rộng để kết hợp các API GraphQL phân tán, trong khi Schema Stitching cung cấp một cách tiếp cận linh hoạt hơn để kết hợp các schema hiện có. Bằng cách xem xét cẩn thận các yêu cầu cụ thể của ứng dụng và sự đánh đổi giữa các kỹ thuật này, bạn có thể chọn phương pháp tốt nhất để xây dựng một Cổng API Frontend mạnh mẽ và hiệu quả.

Hãy nhớ triển khai xác thực và ủy quyền phù hợp, các chiến lược lưu trữ đệm, cũng như giám sát và quan sát để đảm bảo tính bảo mật, hiệu suất và độ tin cậy của gateway của bạn. Bằng cách áp dụng những phương pháp tốt nhất này, bạn có thể khai thác toàn bộ tiềm năng của GraphQL và xây dựng các ứng dụng web hiện đại mang lại trải nghiệm người dùng đặc biệt.